-
Notifications
You must be signed in to change notification settings - Fork 21
to_array_object: type dtype as str, note possibilities #213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
to_array_object: type dtype as str, note possibilities #213
Conversation
b01dec1
to
578ac2f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Listing the accepted dtypes seems useful, but I don't see why we'd want it to be strings rather than dtypes. The latter is much more natural, and it must work because this is still within a single library hence all dtype objects/instances are known entities.
sure sounds good |
The dtype of the array-API-compliant object to return. | ||
Must be one of: | ||
|
||
- namespace.Bool() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the namespace.
seems confusing to me, and I don't think we've used that anywhere else. One of these should work:
Must be an instance of
- `Bool`
- ` Int8`
- etc
or, more concisely:
Must be a boolean or numerical (signed or unsigned integer, or floating-point) dtype that is part of this standard.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks - sure I've removed namespace
do we want to keep Bool()
to remind that it's a class they need to pass?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, sounds good to me. I think it works like it is now.
thanks for your review! |
not all dataframe dtypes are supported by the array api (e.g.
datetime
), so just accepting the same ones and sometimes raisingNotImplementedError
may not be the best experienceHow about just accepting
str
, and listing the allowed strings? These dtypes don't need to store anything (like categories / time unit / time zone), so don't need to be classes anyway.Internally, each implementation can map to the correct object (e.g. for pandas: 'int64' would go to np.int64)